CouchDB nace con la idea de ser una base de datos flexible y altamente escalable para la web.
En los últimos años se ha producido una tendencia, en la industria y la comunidad del software libre, a buscar alternativas a los sistemas de gestión de bases de datos relacionales (SGBDR en adelante).
Algunos de los motivos que justifican esta tendencia son:
Necesidad de alta escalabilidad Mayor flexibilidad en el modelo de datos Reducción de costes (utilización de más máquinas menos potentes)
Algunos ejemplos reseñables de esta nueva tendencia son: Bigtable: Propuesto y desarrollado por Google, es utilizado en multitud de servicios como indexación de la www, Google Earth o Google Finance. Está diseñado para una gran escalabilidad, con cientos de servidores y trabajar con datos estructurados y tipos de demanda muy diferentes entre sí. El resultado es un motor de almacenamiento altamente escalable, muy flexible y que proporciona un gran rendimiento. Amazon Dynamo: Es una gran apuesta y una de las referencias para los desarrolladores de CouchDB. Se trata de un sistema de almacenamiento de pares clave-valor. Se basa en el modelo de consistencia eventual. Busca un equilibrio entre consistencia, disponibilidad y rendimiento, que no había podido encontrarse en los SGBDR Partiendo de este entorno se ha intentado realizar un estudio y un análisis desde un punto de vista práctico de lo que ofrece el proyecto de software libre Apache CouchDB.
HISTORIA
El proyecto de software libre nace en Abril de 2005 de la idea de Damien Katz de crear un nuevo motor de bases de datos orientado a documentos para entornos web. En un primer momento CouchDB estaba escrito en C++ y ya incluía algunas de las características esenciales del proyecto, tales como: la falta de esquema relacional, almacenamiento append-only y actualizaciones atómicas. En estos inicios, el proyecto estaba muy influenciado por Lotus Notes y su idea de base de datos orientada a documentos. Katz presenta el lenguaje de consulta y validación de documentos que, en un principio, será utilizado para CouchDB. Dicho lenguaje, implementado por él, está inspirado en Notes Formula language y Excel Formula language. En Diciembre de 2005, Damien Katz presenta las líneas generales, los objetivos y ambiciones del proyecto. En ese momento se definen algunas de las características más importantes del proyecto en la actualidad:
Plataforma de bases de datos simplificada
Centrada en documentos
No sigue el modelo relacional
Facilita la distribución, alta escalabilidad y la tolerancia a fallos
Preparada para funcionar offline
Replicación bidireccional
Orientada a Internet
Dos puntos de inflexión del proyecto son los siguientes: 1. Febrero 2006: El código completo estará escrito en Erlang. En los siguientes apartados se incidirá en los beneficios que esta elección aporta al proyecto. 2. Abril 2006: CouchDB será accesible únicamente a través de una API HTTP RESTful. Este hecho aporta, como se verá más adelante, gran flexibilidad y potencia la distribución.
La primera versión publicada, únicamente disponible para Windows, la versión 0.2 fue publicada en Agosto del 2006. Otro de los puntos de inflexión y que generó un gran interés fue el anuncio de lo siguiente: 1. Se desecha XML por JSON (JavaScript Notation Object) para la transferencia de datos. 2. Se desecha el lenguaje de consulta y validación ad-hoc (Fabric Formula) y se adopta Javascript con la intención de integrar Mozilla Spidermonkey, el cual será analizado posteriormente en este informe.
Estos dos hechos facilitan la popularización y posicionan a CouchDB como un proyecto muy interesante para aplicaciones web modernas. Para la versión 0.7 ambas características fueron incluidas, así como una interfaz de administración basada en web. Esta versión es la primera que puede considerarse realmente funcional para la gestión de datos. En dicho punto, CouchDB es adoptado por IBM y posteriormente por Apache Foundation con lo que la licencia pasa de ser GNU GPL (General Public License) a ser Apache License. Otro de los pasos hacía los sistemas distribuidos y el software basado en componentes fue el anuncio del uso de MapReduce para consultar los datos y generar vistas sobre ellos. Este modelo de programación es una técnica revolucionaria en el mundo del procesamiento y generación de datos y será analizada posteriormente en este informe. Tras estos hechos, lo más reseñable es que en Noviembre de 2008 CouchDB pasa a ser un proyecto Apache de primer nivel, al lado de otros como Apache HTTP Server, Tomcat, Ant, etc.
En los siguientes apartados se va a describir CouchDB, teniendo en cuenta la versión 0.10 (versión beta oficial a la hora de redactar este documento) y algunas características que ofrecerán las versiones 0.11 y 1.0, que serán presentada a lo largo de 2010.
CARACTERÍSTICAS PRINCIPALES
En el apartado anterior se ha presentado la evolución del proyecto, a la vez que se han mencionado algunas de sus características principales. En este apartado se va a intentar analizar con más detalle qué ofrece CouchDB.
En la página del proyecto en la fundación Apache podemos encontrar la siguiente descripción de CouchDB:
Es un servidor de bases de datos orientado a documentos, accesible via API RESTful JSON.
Ad-hoc y de esquema libre con un espacio plano de direcciones.
Distribuido, con una replicación robusta e incremental con detección y gestión de conflictos bidireccional.
Indexable y consultable, haciendo uso de JavaScript como lenguaje de consulta.
Se puede observar que esta descripción presenta un conjunto de términos muy de moda en la actualidad pero que no ofrecen una visión clara de qué es realmente CouchDB. Realmente CouchDB entra dentro del modelo de almacenamiento denominado par clave-valor (en inglés key-value pair). Este enfoque se ha mencionado en apartados anteriores y en el caso de CouchDB consiste en: Todos los datos se almacenan y manejan en lo que en CouchDb se denominan documentos. Un documento realmente es un objeto en notación JSON. Este objeto es realmente un conjunto de pares clave-valor. Cada documento es independiente del otro. Esto significa que no se fuerza ningún esquema relacional pero el desarrollador puede establecer relaciones entre documentos.
IMPLEMENTACIÓN DE COUCH DB
En este apartado se van a ir presentando y discutiendo aspectos clave la implementación. Empezando por la estructura de sus componentes principales.
COMPONENTES PRINCIPALES DE COUCH DB
Los componentes esenciales son por tanto:
HTTP Client: Es decir, el cliente que realiza peticiones contra el servidor de la base de datos. Este cliente puede ser cualquier aplicación que permita HTTP (navegador, aplicación móvil, aplicación Java, Python, etc.) Este es uno de los puntos fuertes de CouchDB y que potencia su uso en entornos web, así como la orientación al trabajo offline, apoyada por la posibilidad de replicación cuando la aplicación vuelva online (Este aspecto se tratará más en detalle posteriormente en este documento).
Erlang HTTP: Es uno de los componentes más importantes y esta basado en Mochiweb un kit para servidores HTTP ligeros escrito en Erlang. Sirve de apoyo a todas las funciones de control y gestión de HTTP (gestión de peticiones, concurrencia, cabeceras HTTP, encriptado, autentificación, etc. ) utilizadas por el componente mod_couch.
Mod_Couch: Es el núcleo de la máquina virtual Erlang de CouchDB. En este componente se implementa la API y es el encargado de entender y gestionar las diferentes operaciones solicitadas por el cliente HTTP.
View_Engine: Es en este componente donde se realiza todo el proceso de las vistas, los documentos de diseño, la indexación, etc. Las principales operaciones se realizan haciendo uso de arboles B.
Storage_Engine: Es otra de las partes esenciales de CouchDB ya que gestiona las escrituras a disco. Este componente se comunica activamente también con el View Engine y el Replicator debido a que por ejemplo las vistas son incrementales y deben reflejar los cambios escritos a disco.
Replicator: Es el encargado de gestionar la replicación de los documentos (incluyendo documentos de diseño). Es uno de los módulos que necesita mayores mejoras para lograr uno de los principales objetivos de CouchDB que es la distribución entre diferentes dispositivos, tanto online como offline. Por el momento este componentes solo actúa si es activado manual o programáticamente pero no funciona de manera continua. Es decir, los cambios en el maestro no se propagan automáticamente a los esclavos cuando se producen cambios en los datos.
El resto de componentes son externos al núcleo y algunos de ellos no son objetivo principal para la versión 1.0 como el proyecto couchdb-lucene. Otros como Mozilla Spidermonkey, que apoya con JavaScript al motor de Vistas, vienen integrados en la distribución actual pero se están buscando otras alternativas como un motor de vistas nativo escrito en Erlang.
CONCURRENCIA
En este apartado se van analizar dos conceptos clave para entender la manera de funcionar de CouchDB.
CouchDB utiliza MVCC (Multiversion Concurrency Control) como base para el control de la concurrencia. Según la descripción técnica del proyecto en la página de Apache, esto significa que durante una operación de lectura el cliente siempre recibe una versión consistente de los datos. Esta característica, sin embargo, no es realmente diferente de cualquier otro gestor de bases de datos. Por poner un ejemplo MVCC es utilizado, según mi propia experiencia e investigación, en motores de almacenamiento como InnoDB de MySQL. Una característica que he encontrado diferente a la manera de gestionar la concurrencia, respecto a otros gestores, es que una operación de lectura nunca es bloqueada por el servidor de CouchDB y no tiene que esperar a que otras operaciones de lectura o escritura terminen. Esto introduce uno de los aspectos diferenciales de CouchDB y otras nuevas tecnologías de persistencia: la consistencia eventual.
CONSISTENCIA
La consistencia eventual es un modelo de consistencia para sistemas distribuidos planteada por primera vez por Werner Vogels en el ACM Queue. Desde el punto de vista de CouchDB la consistencia eventual se basa en el uso de identificadores de versión y replicación entre los nodos. La resolución de conflictos se basa en los identificadores de versión y timestamps de operación para decidir a través de una función heurística cual es la versión actual del documento. Desde mi punto de vista esta posición está todavía sin madurar ya que se necesitan una gestión de conflictos y replicación más robustas. La idea de los desarrolladores de CouchDB es, por ahora, notificar cuando se ha producido un conflicto y el cliente decide cual es la versión correcta.
SEGURIDAD
La seguridad es uno de los aspectos más débiles a mi parecer de la versión actual e incluso de las siguientes versiones programadas (0.11 y 1.0). Por el momento CouchDB carece de un sistema de autenticación propio y recomienda a los usuarios la implantación de un servidor proxy inverso (como por ejemplo Nginx). Esto es una solución probablemente recomendable en muchos entornos web, pero debería ser capaz de proporcionar una funcionalidad nativa para autenticación. Según se puede leer en la lista de correo de desarrolladores y en el trunk SVN, para las siguientes versiones puede que esté listo el módulo Oauth lo cual es un buen paso en garantizar el futuro del proyecto.
APACHE COUCH DB
Table of Contents
INTRODUCCIÓN
CouchDB nace con la idea de ser una base de datos flexible y altamente escalable para la web.En los últimos años se ha producido una tendencia, en la industria y la comunidad del software libre, a buscar alternativas a los sistemas de gestión de bases de datos relacionales (SGBDR en adelante).
Algunos de los motivos que justifican esta tendencia son:
Necesidad de alta escalabilidad
Mayor flexibilidad en el modelo de datos
Reducción de costes (utilización de más máquinas menos potentes)
Algunos ejemplos reseñables de esta nueva tendencia son:
Bigtable: Propuesto y desarrollado por Google, es utilizado en multitud de servicios como indexación de la www, Google Earth o Google Finance. Está diseñado para una gran escalabilidad, con cientos de servidores y trabajar con datos estructurados y tipos de demanda muy diferentes entre sí. El resultado es un motor de almacenamiento altamente escalable, muy flexible y que proporciona un gran rendimiento.
Amazon Dynamo: Es una gran apuesta y una de las referencias para los desarrolladores de CouchDB. Se trata de un sistema de almacenamiento de pares clave-valor. Se basa en el modelo de consistencia eventual. Busca un equilibrio entre consistencia, disponibilidad y rendimiento, que no había podido encontrarse en los SGBDR
Partiendo de este entorno se ha intentado realizar un estudio y un análisis desde un punto de vista práctico de lo que ofrece el proyecto de software libre Apache CouchDB.
HISTORIA
El proyecto de software libre nace en Abril de 2005 de la idea de Damien Katz de crear un nuevo motor de bases de datos orientado a documentos para entornos web.
En un primer momento CouchDB estaba escrito en C++ y ya incluía algunas de las características esenciales del proyecto, tales como: la falta de esquema relacional, almacenamiento append-only y actualizaciones atómicas. En estos inicios, el proyecto estaba muy influenciado por Lotus Notes y su idea de base de datos orientada a documentos.
Katz presenta el lenguaje de consulta y validación de documentos que, en un principio, será utilizado para CouchDB. Dicho lenguaje, implementado por él, está inspirado en Notes Formula language y Excel Formula language.
En Diciembre de 2005, Damien Katz presenta las líneas generales, los objetivos y ambiciones del proyecto. En ese momento se definen algunas de las características más importantes del proyecto en la actualidad:
Dos puntos de inflexión del proyecto son los siguientes:
1. Febrero 2006: El código completo estará escrito en Erlang. En los siguientes apartados se incidirá en los beneficios que esta elección aporta al proyecto.
2. Abril 2006: CouchDB será accesible únicamente a través de una API HTTP RESTful. Este hecho aporta, como se verá más adelante, gran flexibilidad y potencia la distribución.
La primera versión publicada, únicamente disponible para Windows, la versión 0.2 fue publicada en Agosto del 2006.
Otro de los puntos de inflexión y que generó un gran interés fue el anuncio de lo siguiente:
1. Se desecha XML por JSON (JavaScript Notation Object) para la transferencia de datos.
2. Se desecha el lenguaje de consulta y validación ad-hoc (Fabric Formula) y se adopta Javascript con la intención de integrar Mozilla Spidermonkey, el cual será analizado posteriormente en este informe.
Estos dos hechos facilitan la popularización y posicionan a CouchDB como un proyecto muy interesante para aplicaciones web modernas.
Para la versión 0.7 ambas características fueron incluidas, así como una interfaz de administración basada en web. Esta versión es la primera que puede considerarse realmente funcional para la gestión de datos. En dicho punto, CouchDB es adoptado por IBM y posteriormente por Apache Foundation con lo que la licencia pasa de ser GNU GPL (General Public License) a ser Apache License.
Otro de los pasos hacía los sistemas distribuidos y el software basado en componentes fue el anuncio del uso de MapReduce para consultar los datos y generar vistas sobre ellos. Este modelo de programación es una técnica revolucionaria en el mundo del procesamiento y generación de datos y será analizada posteriormente en este informe.
Tras estos hechos, lo más reseñable es que en Noviembre de 2008 CouchDB pasa a ser un proyecto Apache de primer nivel, al lado de otros como Apache HTTP Server, Tomcat, Ant, etc.
En los siguientes apartados se va a describir CouchDB, teniendo en cuenta la versión 0.10 (versión beta oficial a la hora de redactar este documento) y algunas características que ofrecerán las versiones 0.11 y 1.0, que serán presentada a lo largo de 2010.
CARACTERÍSTICAS PRINCIPALES
En el apartado anterior se ha presentado la evolución del proyecto, a la vez que se han mencionado algunas de sus características principales. En este apartado se va a intentar analizar con más detalle qué ofrece CouchDB.
En la página del proyecto en la fundación Apache podemos encontrar la siguiente descripción de CouchDB:
Se puede observar que esta descripción presenta un conjunto de términos muy de moda en la actualidad pero que no ofrecen una visión clara de qué es realmente CouchDB.
Realmente CouchDB entra dentro del modelo de almacenamiento denominado par clave-valor (en inglés key-value pair). Este enfoque se ha mencionado en apartados anteriores y en el caso de CouchDB consiste en:
Todos los datos se almacenan y manejan en lo que en CouchDb se denominan documentos.
Un documento realmente es un objeto en notación JSON. Este objeto es realmente un conjunto de pares clave-valor.
Cada documento es independiente del otro. Esto significa que no se fuerza ningún esquema relacional pero el desarrollador puede establecer relaciones entre documentos.
IMPLEMENTACIÓN DE COUCH DB
En este apartado se van a ir presentando y discutiendo aspectos clave la implementación. Empezando por la estructura de sus componentes principales.
COMPONENTES PRINCIPALES DE COUCH DB
Los componentes esenciales son por tanto:
El resto de componentes son externos al núcleo y algunos de ellos no son objetivo principal para la versión 1.0 como el proyecto couchdb-lucene. Otros como Mozilla Spidermonkey, que apoya con JavaScript al motor de Vistas, vienen integrados en la distribución actual pero se están buscando otras alternativas como un motor de vistas nativo escrito en Erlang.
CONCURRENCIA
En este apartado se van analizar dos conceptos clave para entender la manera de funcionar de CouchDB.
CouchDB utiliza MVCC (Multiversion Concurrency Control) como base para el control de la concurrencia. Según la descripción técnica del proyecto en la página de Apache, esto significa que durante una operación de lectura el cliente siempre recibe una versión consistente de los datos.
Esta característica, sin embargo, no es realmente diferente de cualquier otro gestor de bases de datos. Por poner un ejemplo MVCC es utilizado, según mi propia experiencia e investigación, en motores de almacenamiento como InnoDB de MySQL. Una característica que he encontrado diferente a la manera de gestionar la concurrencia, respecto a otros gestores, es que una operación de lectura nunca es bloqueada por el servidor de CouchDB y no tiene que esperar a que otras operaciones de lectura o escritura terminen. Esto introduce uno de los aspectos diferenciales de CouchDB y otras nuevas tecnologías de persistencia: la consistencia eventual.
CONSISTENCIA
La consistencia eventual es un modelo de consistencia para sistemas distribuidos planteada por primera vez por Werner Vogels en el ACM Queue.
Desde el punto de vista de CouchDB la consistencia eventual se basa en el uso de identificadores de versión y replicación entre los nodos.
La resolución de conflictos se basa en los identificadores de versión y timestamps de operación para decidir a través de una función heurística cual es la versión actual del documento.
Desde mi punto de vista esta posición está todavía sin madurar ya que se necesitan una gestión de conflictos y replicación más robustas. La idea de los desarrolladores de CouchDB es, por ahora, notificar cuando se ha producido un conflicto y el cliente decide cual es la versión correcta.
SEGURIDAD
La seguridad es uno de los aspectos más débiles a mi parecer de la versión actual e incluso de las siguientes versiones programadas (0.11 y 1.0).
Por el momento CouchDB carece de un sistema de autenticación propio y recomienda a los usuarios la implantación de un servidor proxy inverso (como por ejemplo Nginx). Esto es una solución probablemente recomendable en muchos entornos web, pero debería ser capaz de proporcionar una funcionalidad nativa para autenticación.
Según se puede leer en la lista de correo de desarrolladores y en el trunk SVN, para las siguientes versiones puede que esté listo el módulo Oauth lo cual es un buen paso en garantizar el futuro del proyecto.